1. Technical Field
This invention relates to electronic control units, and more particularly to a control unit for controlling multiple control objects in accordance with an object-oriented program in a manner that minimizes the amount of required memory storage space for queuing of inter-object messages.
2. Related Art
Conventionally, an electronic control unit for a vehicle engine includes an engine control program with various types of control schemes. For example, regarding fuel injection control, programs exist for ordinary injection control synchronized with engine speed, injection control not synchronized with engine speed, and fuel cut control for times of high engine speeds.
However, as each of the programs includes programming code that is redundant with that of other programs, additional memory is required to store the programs, and program development time is increased. For example, in the above-mentioned example of fuel injection control, identical control code for driving injectors (fuel injection valves) is redundantly provided in each of the programs. Therefore, when for example control specifications have to be changed for these redundant code sections, it is necessary for the code in each of the programs to be changed, thereby greatly increasing the time required to make such changes.
Object-oriented programming enables the above-mentioned programming code redundancies to be greatly reduced. Such programming includes several objects, with each object being a software module formed by bringing together data and a program (hereinafter called a method) for processing that data. In other words, in object-oriented programming, all the functions of a control program are fractionalized into unit functions, and objects are prepared for those unit functions. Through what is known as inter-object message communication, message exchanges are carried out between objects, thereby enabling the objects to be linked together.
Referring to FIG. 28, a program for controlling engine idling speed based on object-oriented programming will be described. In FIG. 28, objects are represented by vertical lines, and message exchanges between these objects are represented by left-right direction arrows. Also, the rectangular boxes on the object lines represent object processing.
At this point it should be noted that, in this specification, expressions such as xe2x80x9cthe object does . . . xe2x80x9d and xe2x80x9cobjects do . . . xe2x80x9d indicate functions realized by the CPU as it executes methods of objects in carrying out the above-mentioned actions. Further, phrases such as xe2x80x9cthe object operatesxe2x80x9d indicates the CPU executing a method of that object.
Regarding the functions of the objects shown in FIG. 28, the ISC object is an object for calculating a target throttle aperture for bringing the engine speed to an optimum idling speed based on the engine water temperature value. The water temperature sensor object is an object for converting a digital value obtained by A/D-converting an analog signal from an engine water temperature sensor into a water temperature value. The A/D-converter object is an object for controlling an A/D-converter for converting the analog signal from the water temperature sensor into a digital value. The throttle controller object is an object for controlling the throttle valve of the engine to the target throttle aperture calculated by the ISC object.
Next, the content of processing realized by the objects of FIG. 28 will be explained. During idling speed control timing, the ISC object starts to operate (that is, the CPU starts to execute a method of the ISC object). Then, as shown by [1] of FIG. 28, the ISC object sends a water temperature acquisition request message to the water temperature sensor object.
Consequently, the water temperature sensor object operates, and as shown by [2] of FIG. 28, sends a water temperature A/D value acquisition request message to the A/D-converter object. Along with the water temperature A/D value acquisition request method, the A/D-converter object converts the analog signal from the water temperature sensor into a digital signal.
The A/D-converter object, when it has finished the above-mentioned computation, as shown by [3] of FIG. 28, sends a water temperature A/D value acquisition response message (that is, a message to the effect that digital conversion of the water temperature sensor has finished) to the water temperature sensor object. When this happens, the water temperature sensor object calculates a water temperature value based on the computation results of the A/D-converter object. After this calculation, as shown by [4] of FIG. 28, the water temperature sensor object sends a water temperature acquisition response message (that is, a message to the effect that the calculation of a water temperature value has finished) to the ISC object.
Subsequently, along with the above-mentioned water temperature acquisition response message, the ISC object calculates a target throttle aperture based on the water temperature value thus calculated. The ISC object then sends a throttle setting request message (that is, a message showing that the target throttle aperture has been calculated) to the throttle controller object as shown by [5] of FIG. 28.
When this happens, the throttle controller object operates, and controls a throttle valve of the engine to the calculated target throttle aperture. The engine speed is thereby controlled to an optimum idling speed.
Therefore, in the above-described object-oriented program, by virtual inter-object message communication wherein objects dispatch messages constituting processing requests to other objects to cause the other objects to operate, the processing order of the objects is determined.
If a program is created based on object-oriented programming, it becomes easy to bring together common parts of the program, and, compared to the above-discussed programs that have redundant programming code, amendment of the object-oriented program becomes simple if program specifications are changed.
When a program is created through object-oriented programming, it is necessary to consider the method of inter-object processing request exchange (inter-object message communication). For such communication, it is conceivable to apply a previously known technique using function calls for inter-object message communication. With function calls, as shown in FIG. 29, a command calling the object method to be processed next is pre-written. When inter-object message communication is to be carried out successively, a command calling another object method is pre-written in the called object method.
Specifically, as shown in FIG. 29, during execution of a method of an object A, a method of an object B is called. Further, during execution of the method of the object B, a method of an object C is called. That is, by function calls, messages constituting processing requests are dispatched to other objects.
As methods for utilizing memory for executing this kind of program, there are active (memory is not secured for storing specific data, but is secured when necessary, and is released when not needed) and static (while the microcomputer is operating, memory is secured for exclusive use in correspondence with content to be stored) methods. In the case of active utilization, memory can be secured universally, irrespective of the content (size/number) of the data, and limited memory resources can be utilized effectively.
For active memory utilization, normally, memory area is managed by the computer operating system (OS). When managed by the OS, system calls such as memory area acquisition and release commands are executed with respect to the OS, and the processing load of the program is large, because memory area provision is secured universally, irrespective of the content (size/number) of the data. Therefore, it is desirable for memory to be managed statically to increase the operating speed, and to be constructed so that it can be actively managed.
However, with the method described above using function calls, execution of the method of the side that made the call is temporarily suspended. After the method of the side that was called is executed, execution of the method that had been suspended is restarted. Thus, to restart the execution of the method that had been suspended, the internal state of the microcomputer before the suspension (that is, the values of the program counters and various registers) must be stored in a stack area of a RAM, thereby requiring additional memory.
In particular, as the number of nestings increases (that is, combinations of calls formed in multiple layers), the amount of RAM consumed increases. In a device such as an electronic control unit whose memory resources are limited, this additional RAM requirement becomes problematic. Furthermore, concerning the amount of RAM required during calling, because the program execution position and values of variables to be used after execution resumption that should be stored change according to sensor inputs and the execution states of other programs, it is difficult to predict the amount of memory that must be pre-secured, thereby making it difficult to use a static memory-type method.
In view of the above, it is an object of the present invention to provide an electronic control unit that can execute object-oriented programming without consuming a large amount of memory.
More particularly, it is an object of the present invention to provide an electronic control unit capable of executing object-oriented programming to control a control target in real time with minimum memory requirements compared to the memory requirements of conventional control programs.
An electronic control unit according to the invention includes a plurality of unit processors for respectively carrying out processing, in accordance with objects of an object-oriented program, for realizing unit functions that control the objects.
The unit processors are realized by the processor of a microcomputer operating in accordance with an object-oriented program. That is, the processor executes a method of an object to carry out processing for realizing a function allocated to that object. In the electronic control unit of the present invention, as a premise thereof, one of the plurality of unit processors selectively carries out a processing operation, and, by the various unit processors dispatching messages constituting processing requests to other unit processors, the unit processors that are the output destinations of those messages carry out processing.
The electronic control unit of the present invention secures in advance a storage memory area for exclusive use, and stores messages dispatched by the unit processor in this dedicated memory area. Also, the electronic control unit reads a message stored in the message dedicated memory area, and starts processing in whichever of the unit processors is the output destination of the read message.
Therefore, with the electronic control unit of the present invention, memory can be used without the need for reliance on an operating system. Therefore, it is possible to process objects obtained by fractionalizing a program for controlling a control object at a high operating speed into unit functions. Furthermore, because only messages required to start the processing of the unit processors are stored in the memory area secured for exclusive use, the amount of memory that should be secured can be estimated easily, thereby making it possible to reduce the amount of required memory.